<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

<html>
<head>
  <meta name="generator" content=
  "HTML Tidy for Linux/x86 (vers 7 December 2008), see www.w3.org">

  <title>Releasing a New Version</title>
  <meta name="GENERATOR" content=
  "Modular DocBook HTML Stylesheet Version 1.79">
  <link rel="HOME" title="Privoxy Developer Manual" href="index.html">
  <link rel="PREVIOUS" title="Testing Guidelines" href="testing.html">
  <link rel="NEXT" title="Update the Webserver" href="webserver-update.html">
  <link rel="STYLESHEET" type="text/css" href="../p_doc.css">
  <meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
  <style type="text/css">
body {
  background-color: #EEEEEE;
  color: #000000;
  }
  :link { color: #0000FF }
  :visited { color: #840084 }
  :active { color: #0000FF }
  tt.c5 {font-style: italic}
  td.c4 {font-weight: bold}
  table.c3 {background-color: #E0E0E0}
  span.c2 {font-style: italic}
  hr.c1 {text-align: left}
  </style>
</head>

<body class="SECT1">
  <div class="NAVHEADER">
    <table summary="Header navigation table" width="100%" border="0"
    cellpadding="0" cellspacing="0">
      <tr>
        <th colspan="3" align="center">Privoxy Developer Manual</th>
      </tr>

      <tr>
        <td width="10%" align="left" valign="bottom"><a href="testing.html"
        accesskey="P">Prev</a></td>

        <td width="80%" align="center" valign="bottom"></td>

        <td width="10%" align="right" valign="bottom"><a href=
        "webserver-update.html" accesskey="N">Next</a></td>
      </tr>
    </table>
    <hr class="c1" width="100%">
  </div>

  <div class="SECT1">
    <h1 class="SECT1"><a name="NEWRELEASE" id="NEWRELEASE">6. Releasing a New
    Version</a></h1>

    <p>When we release versions of <span class="APPLICATION">Privoxy</span>,
    our work leaves our cozy secret lab and has to work in the cold
    RealWorld[tm]. Once it is released, there is no way to call it back, so
    it is very important that great care is taken to ensure that everything
    runs fine, and not to introduce problems in the very last minute.</p>

    <p>So when releasing a new version, please adhere exactly to the
    procedure outlined in this chapter.</p>

    <p>The following programs are required to follow this process: <tt class=
    "FILENAME">ncftpput</tt> (ncftp), <tt class="FILENAME">scp, ssh</tt>
    (ssh), <tt class="FILENAME">gmake</tt> (GNU's version of make), autoconf,
    cvs.</p>

    <div class="SECT2">
      <h2 class="SECT2"><a name="VERSIONNUMBERS" id="VERSIONNUMBERS">6.1.
      Version numbers</a></h2>

      <p>First you need to determine which version number the release will
      have. <span class="APPLICATION">Privoxy</span> version numbers consist
      of three numbers, separated by dots, like in X.Y.Z (e.g. 3.0.0),
      where:</p>

      <ul>
        <li>
          <p>X, the version major, is rarely ever changed. It is increased by
          one if turning a development branch into stable substantially
          changes the functionality, user interface or configuration syntax.
          Majors 1 and 2 were <span class="APPLICATION">Junkbuster</span>,
          and 3 will be the first stable <span class=
          "APPLICATION">Privoxy</span> release.</p>
        </li>

        <li>
          <p>Y, the version minor, represents the branch within the major
          version. At any point in time, there are two branches being
          maintained: The stable branch, with an even minor, say, 2N, in
          which no functionality is being added and only bug-fixes are made,
          and 2N+1, the development branch, in which the further development
          of <span class="APPLICATION">Privoxy</span> takes place. This
          enables us to turn the code upside down and inside out, while at
          the same time providing and maintaining a stable version. The minor
          is reset to zero (and one) when the major is incremented. When a
          development branch has matured to the point where it can be turned
          into stable, the old stable branch 2N is given up (i.e. no longer
          maintained), the former development branch 2N+1 becomes the new
          stable branch 2N+2, and a new development branch 2N+3 is
          opened.</p>
        </li>

        <li>
          <p>Z, the point or sub version, represents a release of the
          software within a branch. It is therefore incremented immediately
          before each code freeze. In development branches, only the even
          point versions correspond to actual releases, while the odd ones
          denote the evolving state of the sources on CVS in between. It
          follows that Z is odd on CVS in development branches most of the
          time. There, it gets increased to an even number immediately before
          a code freeze, and is increased to an odd number again immediately
          thereafter. This ensures that builds from CVS snapshots are easily
          distinguished from released versions. The point version is reset to
          zero when the minor changes.</p>

          <p>Stable branches work a little differently, since there should be
          little to no development happening in such branches. Remember, only
          bugfixes, which presumably should have had some testing before
          being committed. Stable branches will then have their version
          reported as <tt class="LITERAL">0.0.0</tt>, during that period
          between releases when changes are being added. This is to denote
          that this code is <span class="emphasis EMPHASIS c2">not for
          release</span>. Then as the release nears, the version is bumped
          according: e.g. <tt class="LITERAL">3.0.1 -&gt; 0.0.0 -&gt;
          3.0.2</tt>.</p>
        </li>
      </ul>

      <p>In summary, the main CVS trunk is the development branch where new
      features are being worked on for the next stable series. This should
      almost always be where the most activity takes place. There is always
      at least one stable branch from the trunk, e.g now it is <tt class=
      "LITERAL">3.0</tt>, which is only used to release stable versions. Once
      the initial *.0 release of the stable branch has been done, then as a
      rule, only bugfixes that have had prior testing should be committed to
      the stable branch. Once there are enough bugfixes to justify a new
      release, the version of this branch is again incremented Example: 3.0.0
      -&gt; 3.0.1 -&gt; 3.0.2, etc are all stable releases from within the
      stable branch. 3.1.x is currently the main trunk, and where work on
      3.2.x is taking place. If any questions, please post to the devel list
      <span class="emphasis EMPHASIS c2">before</span> committing to a stable
      branch!</p>

      <p>Developers should remember too that if they commit a bugfix to the
      stable branch, this will more than likely require a separate submission
      to the main trunk, since these are separate development trees within
      CVS. If you are working on both, then this would require at least two
      separate check outs (i.e main trunk, <span class=
      "emphasis EMPHASIS c2">and</span> the stable release branch, which is
      <tt class="LITERAL">v_3_0_branch</tt> at the moment).</p>
    </div>

    <div class="SECT2">
      <h2 class="SECT2"><a name="BEFORERELEASE" id="BEFORERELEASE">6.2.
      Before the Release: Freeze</a></h2>

      <p>The following <span class="emphasis EMPHASIS c2">must be done by one
      of the developers</span> prior to each new release.</p>

      <ul>
        <li>
          <p>Make sure that everybody who has worked on the code in the last
          couple of days has had a chance to yell <span class=
          "QUOTE">"no!"</span> in case they have pending changes/fixes in
          their pipelines. Announce the freeze so that nobody will interfere
          with last minute changes.</p>
        </li>

        <li>
          <p>Increment the version number (point from odd to even in
          development branches!) in <tt class="FILENAME">configure.in</tt>.
          (RPM spec files will need to be incremented as well.)</p>
        </li>

        <li>
          <p>If <tt class="FILENAME">default.action</tt> has changed since
          last release (i.e. software release or standalone actions file
          release), bump up its version info to A.B in this line:</p>

          <table class="c3" border="0" width="90%">
            <tr>
              <td>
                <pre class="PROGRAMLISTING">
  {+add-header{X-Actions-File-Version: A.B} -filter -no-popups}
</pre>
              </td>
            </tr>
          </table>

          <p>Then change the version info in doc/webserver/actions/index.php,
          line: '$required_actions_file_version = "A.B";'</p>
        </li>

        <li>
          <p>All documentation should be rebuild after the version bump.
          Finished docs should be then be committed to CVS (for those without
          the ability to build these). Some docs may require rather obscure
          processing tools. <tt class="FILENAME">config</tt>, the man page
          (and the html version of the man page), and the PDF docs fall in
          this category. REAMDE, the man page, AUTHORS, and config should all
          also be committed to CVS for other packagers. The formal docs
          should be uploaded to the webserver. See the Section "Updating the
          webserver" in this manual for details.</p>
        </li>

        <li>
          <p>The <i class="CITETITLE">User Manual</i> is also used for
          context sensitive help for the CGI editor. This is version
          sensitive, so that the user will get appropriate help for his/her
          release. So with each release a fresh version should be uploaded to
          the webserver (this is in addition to the main <i class=
          "CITETITLE">User Manual</i> link from the main page since we need
          to keep manuals for various versions available). The CGI pages will
          link to something like <tt class=
          "LITERAL">http://privoxy.org/$(VERSION)/user-manual/</tt>. This
          will need to be updated for each new release. There is no Makefile
          target for this at this time!!! It needs to be done manually.</p>
        </li>

        <li>
          <p>All developers should look at the <tt class=
          "FILENAME">ChangeLog</tt> and make sure noteworthy changes are
          referenced.</p>
        </li>

        <li>
          <p><span class="emphasis EMPHASIS c2">Commit all files that were
          changed in the above steps!</span></p>
        </li>

        <li>
          <p>Tag all files in CVS with the version number with <span class=
          "QUOTE">"<b class="COMMAND">cvs tag v_X_Y_Z</b>"</span>. Don't use
          vX_Y_Z, ver_X_Y_Z, v_X.Y.Z (won't work) etc.</p>
        </li>

        <li>
          <p>If the release was in a development branch, increase the point
          version from even to odd (X.Y.(Z+1)) again in <tt class=
          "FILENAME">configure.in</tt> and commit your change.</p>
        </li>

        <li>
          <p>On the webserver, copy the user manual to a new top-level
          directory called <tt class="FILENAME">X.Y.Z</tt>. This ensures that
          help links from the CGI pages, which have the version as a prefix,
          will go into the right version of the manual. If this is a
          development branch release, also symlink <tt class=
          "FILENAME">X.Y.(Z-1)</tt> to <tt class="FILENAME">X.Y.Z</tt> and
          <tt class="FILENAME">X.Y.(Z+1)</tt> to <tt class="FILENAME">.</tt>
          (i.e. dot).</p>
        </li>
      </ul>
    </div>

    <div class="SECT2">
      <h2 class="SECT2"><a name="THERELEASE" id="THERELEASE">6.3. Building
      and Releasing the Packages</a></h2>

      <p>Now the individual packages can be built and released. Note that for
      GPL reasons the first package to be released is always the source
      tarball.</p>

      <p>For <span class="emphasis EMPHASIS c2">all</span> types of packages,
      including the source tarball, <span class="emphasis EMPHASIS c2">you
      must make sure that you build from clean sources by exporting the right
      version from CVS into an empty directory</span> (just press return when
      asked for a password):</p>

      <table class="c3" border="0" width="100%">
        <tr>
          <td>
            <pre class="PROGRAMLISTING">
  mkdir dist # delete or choose different name if it already exists
  cd dist
  cvs -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa login
  cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa export -r v_X_Y_Z current
</pre>
          </td>
        </tr>
      </table>

      <p><span class="emphasis EMPHASIS c2">Do NOT change</span> a single
      bit, including, but not limited to version information after export
      from CVS. This is to make sure that all release packages, and with
      them, all future bug reports, are based on exactly the same code.</p>

      <div class="WARNING">
        <table class="WARNING" border="1" width="100%">
          <tr>
            <td class="c4" align="center">Warning</td>
          </tr>

          <tr>
            <td align="left">
              <p>Every significant release of Privoxy has included at least
              one package that either had incorrect versions of files,
              missing files, or incidental leftovers from a previous build
              process that gave unknown numbers of users headaches to try to
              figure out what was wrong. PLEASE, make sure you are using
              pristene sources, and are following the prescribed process!</p>
            </td>
          </tr>
        </table>
      </div>

      <p>Please find additional instructions for the source tarball and the
      individual platform dependent binary packages below. And details on the
      Sourceforge release process below that.</p>

      <div class="SECT3">
        <h3 class="SECT3"><a name="PACK-GUIDELINES" id=
        "PACK-GUIDELINES">6.3.1. Note on Privoxy Packaging</a></h3>

        <p>Please keep these general guidelines in mind when putting together
        your package. These apply to <span class=
        "emphasis EMPHASIS c2">all</span> platforms!</p>

        <ul>
          <li>
            <p><span class="APPLICATION">Privoxy</span> <span class=
            "emphasis EMPHASIS c2">requires</span> write access to: all
            <tt class="FILENAME">*.action</tt> files, all logfiles, and the
            <tt class="FILENAME">trust</tt> file. You will need to determine
            the best way to do this for your platform.</p>
          </li>

          <li>
            <p>Please include up to date documentation. At a bare
            minimum:</p>

            <table border="0">
              <tbody>
                <tr>
                  <td><tt class="FILENAME">LICENSE</tt> (top-level
                  directory)</td>
                </tr>
              </tbody>
            </table>

            <table border="0">
              <tbody>
                <tr>
                  <td><tt class="FILENAME">README</tt> (top-level
                  directory)</td>
                </tr>
              </tbody>
            </table>

            <table border="0">
              <tbody>
                <tr>
                  <td><tt class="FILENAME">AUTHORS</tt> (top-level
                  directory)</td>
                </tr>
              </tbody>
            </table>

            <table border="0">
              <tbody>
                <tr>
                  <td><tt class="FILENAME">man page</tt> (top-level
                  directory, Unix-like platforms only)</td>
                </tr>
              </tbody>
            </table>

            <table border="0">
              <tbody>
                <tr>
                  <td><tt class="FILENAME">The User Manual</tt>
                  (doc/webserver/user-manual/)</td>
                </tr>
              </tbody>
            </table>

            <table border="0">
              <tbody>
                <tr>
                  <td><tt class="FILENAME">FAQ</tt> (doc/webserver/faq/)</td>
                </tr>
              </tbody>
            </table>

            <p>Also suggested: <tt class="FILENAME">Developer Manual</tt>
            (doc/webserver/developer-manual) and <tt class=
            "FILENAME">ChangeLog</tt> (top-level directory). <tt class=
            "FILENAME">FAQ</tt> and the manuals are HTML docs. There are also
            text versions in <tt class="FILENAME">doc/text/</tt> which could
            conceivably also be included.</p>

            <p>The documentation has been designed such that the manuals are
            linked to each other from parallel directories, and should be
            packaged that way. <tt class="FILENAME">privoxy-index.html</tt>
            can also be included and can serve as a focal point for docs and
            other links of interest (and possibly renamed to <tt class=
            "FILENAME">index.html</tt>). This should be one level up from the
            manuals. There is a link also on this page to an HTMLized version
            of the man page. To avoid 404 for this, it is in CVS as
            <tt class="FILENAME">doc/webserver/man-page/privoxy-man-page.html</tt>,
            and should be included along with the manuals. There is also a
            css stylesheets that can be included for better presentation:
            <tt class="FILENAME">p_doc.css</tt>. This should be in the same
            directory with <tt class="FILENAME">privoxy-index.html</tt>,
            (i.e. one level up from the manual directories).</p>
          </li>

          <li>
            <p><tt class="FILENAME">user.action</tt> and <tt class=
            "FILENAME">user.filter</tt> are designed for local preferences.
            Make sure these do not get overwritten! <tt class=
            "FILENAME">config</tt> should not be overwritten either. This has
            especially important configuration data in it. <tt class=
            "FILENAME">trust</tt> should be left in tact as well.</p>
          </li>

          <li>
            <p>Other configuration files (<tt class=
            "FILENAME">default.action</tt> and <tt class=
            "FILENAME">default.filter</tt>) should be installed as the new
            defaults, but all previously installed configuration files should
            be preserved as backups. This is just good manners :-) These
            files are likely to change between releases and contain important
            new features and bug fixes.</p>
          </li>

          <li>
            <p>Please check platform specific notes in this doc, if you
            haven't done <span class="QUOTE">"Privoxy"</span> packaging
            before for other platform specific issues. Conversely, please add
            any notes that you know are important for your platform (or
            contact one of the doc maintainers to do this if you can't).</p>
          </li>

          <li>
            <p>Packagers should do a <span class="QUOTE">"clean"</span>
            install of their package after building it. So any previous
            installs should be removed first to ensure the integrity of the
            newly built package. Then run the package for a while to make
            sure there are no obvious problems, before uploading.</p>
          </li>
        </ul>
      </div>

      <div class="SECT3">
        <h3 class="SECT3"><a name="NEWRELEASE-TARBALL" id=
        "NEWRELEASE-TARBALL">6.3.2. Source Tarball</a></h3>

        <p>First, <span class="emphasis EMPHASIS c2">make sure that you have
        freshly exported the right version into an empty directory</span>.
        (See "Building and releasing packages" above). Then run:</p>

        <table class="c3" border="0" width="100%">
          <tr>
            <td>
              <pre class="PROGRAMLISTING">
  cd current
  autoheader &amp;&amp; autoconf &amp;&amp; ./configure
</pre>
            </td>
          </tr>
        </table>

        <p>Then do:</p>

        <table class="c3" border="0" width="100%">
          <tr>
            <td>
              <pre class="PROGRAMLISTING">
  make tarball-dist
</pre>
            </td>
          </tr>
        </table>

        <p>To upload the package to Sourceforge, simply issue</p>

        <table class="c3" border="0" width="100%">
          <tr>
            <td>
              <pre class="PROGRAMLISTING">
  make tarball-upload
</pre>
            </td>
          </tr>
        </table>

        <p>Go to the displayed URL and release the file publicly on
        Sourceforge. For the change log field, use the relevant section of
        the <tt class="FILENAME">ChangeLog</tt> file.</p>
      </div>

      <div class="SECT3">
        <h3 class="SECT3"><a name="NEWRELEASE-RPM" id="NEWRELEASE-RPM">6.3.3.
        SuSE, Conectiva or Red Hat RPM</a></h3>

        <p>In following text, replace <tt class="REPLACEABLE c5">dist</tt>
        with either <span class="QUOTE">"rh"</span> for Red Hat or
        <span class="QUOTE">"suse"</span> for SuSE.</p>

        <p>First, <span class="emphasis EMPHASIS c2">make sure that you have
        freshly exported the right version into an empty directory</span>.
        (See "Building and releasing packages" above).</p>

        <p>As the only exception to not changing anything after export from
        CVS, now examine the file <tt class=
        "FILENAME">privoxy-</tt><tt class="REPLACEABLE c5">dist</tt><tt class="FILENAME">.spec</tt>
        and make sure that the version information and the RPM release number
        are correct. The RPM release numbers for each version start at one.
        Hence it must be reset to one if this is the first RPM for <tt class=
        "REPLACEABLE c5">dist</tt> which is built from version X.Y.Z. Check
        the <a href=
        "http://sourceforge.net/project/showfiles.php?group_id=11118" target=
        "_top">file list</a> if unsure. Else, it must be set to the highest
        already available RPM release number for that version plus one.</p>

        <p>Then run:</p>

        <table class="c3" border="0" width="100%">
          <tr>
            <td>
              <pre class="PROGRAMLISTING">
  cd current
  autoheader &amp;&amp; autoconf &amp;&amp; ./configure
</pre>
            </td>
          </tr>
        </table>

        <p>Then do</p>

        <table class="c3" border="0" width="100%">
          <tr>
            <td>
              <pre class="PROGRAMLISTING">
  make <tt class="REPLACEABLE c5">dist</tt>-dist
</pre>
            </td>
          </tr>
        </table>

        <p>To upload the package to Sourceforge, simply issue</p>

        <table class="c3" border="0" width="100%">
          <tr>
            <td>
              <pre class="PROGRAMLISTING">
  make <tt class="REPLACEABLE c5">dist</tt>-upload <tt class=
"REPLACEABLE c5">rpm_packagerev</tt>
</pre>
            </td>
          </tr>
        </table>

        <p>where <tt class="REPLACEABLE c5">rpm_packagerev</tt> is the RPM
        release number as determined above. Go to the displayed URL and
        release the file publicly on Sourceforge. Use the release notes and
        change log from the source tarball package.</p>
      </div>

      <div class="SECT3">
        <h3 class="SECT3"><a name="NEWRELEASE-OS2" id="NEWRELEASE-OS2">6.3.4.
        OS/2</a></h3>

        <p>First, <span class="emphasis EMPHASIS c2">make sure that you have
        freshly exported the right version into an empty directory</span>.
        (See "Building and releasing packages" above). Then get the OS/2
        Setup module:</p>

        <table class="c3" border="0" width="100%">
          <tr>
            <td>
              <pre class="PROGRAMLISTING">
  cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co os2setup
</pre>
            </td>
          </tr>
        </table>

        <p>You will need a mix of development tools. The main compilation
        takes place with IBM Visual Age C++. Some ancillary work takes place
        with GNU tools, available from various sources like hobbes.nmsu.edu.
        Specificially, you will need <tt class="FILENAME">autoheader</tt>,
        <tt class="FILENAME">autoconf</tt> and <tt class="FILENAME">sh</tt>
        tools. The packaging takes place with WarpIN, available from various
        sources, including its home page: <a href=
        "http://www.xworkplace.org/" target="_top">xworkplace</a>.</p>

        <p>Change directory to the <tt class="FILENAME">os2setup</tt>
        directory. Edit the os2build.cmd file to set the final executable
        filename. For example,</p>

        <table class="c3" border="0" width="100%">
          <tr>
            <td>
              <pre class="PROGRAMLISTING">
  installExeName='privoxyos2_setup_X.Y.Z.exe'
</pre>
            </td>
          </tr>
        </table>

        <p>Next, edit the <tt class="FILENAME">IJB.wis</tt> file so the
        release number matches in the <tt class="FILENAME">PACKAGEID</tt>
        section:</p>

        <table class="c3" border="0" width="100%">
          <tr>
            <td>
              <pre class="PROGRAMLISTING">
  PACKAGEID="Privoxy Team\Privoxy\Privoxy Package\X\Y\Z"
</pre>
            </td>
          </tr>
        </table>

        <p>You're now ready to build. Run:</p>

        <table class="c3" border="0" width="100%">
          <tr>
            <td>
              <pre class="PROGRAMLISTING">
  os2build
</pre>
            </td>
          </tr>
        </table>

        <p>You will find the WarpIN-installable executable in the <tt class=
        "FILENAME">./files</tt> directory. Upload this anonymously to
        <tt class="FILENAME">uploads.sourceforge.net/incoming</tt>, create a
        release for it, and you're done. Use the release notes and Change Log
        from the source tarball package.</p>
      </div>

      <div class="SECT3">
        <h3 class="SECT3"><a name="NEWRELEASE-SOLARIS" id=
        "NEWRELEASE-SOLARIS">6.3.5. Solaris</a></h3>

        <p>Login to Sourceforge's compilefarm via ssh:</p>

        <table class="c3" border="0" width="100%">
          <tr>
            <td>
              <pre class="PROGRAMLISTING">
  ssh cf.sourceforge.net
</pre>
            </td>
          </tr>
        </table>

        <p>Choose the right operating system (not the Debian one). When
        logged in, <span class="emphasis EMPHASIS c2">make sure that you have
        freshly exported the right version into an empty directory</span>.
        (See "Building and releasing packages" above). Then run:</p>

        <table class="c3" border="0" width="100%">
          <tr>
            <td>
              <pre class="PROGRAMLISTING">
  cd current
  autoheader &amp;&amp; autoconf &amp;&amp; ./configure
</pre>
            </td>
          </tr>
        </table>

        <p>Then run</p>

        <table class="c3" border="0" width="100%">
          <tr>
            <td>
              <pre class="PROGRAMLISTING">
  gmake solaris-dist
</pre>
            </td>
          </tr>
        </table>

        <p>which creates a gzip'ed tar archive. Sadly, you cannot use
        <b class="COMMAND">make solaris-upload</b> on the Sourceforge machine
        (no ncftpput). You now have to manually upload the archive to
        Sourceforge's ftp server and release the file publicly. Use the
        release notes and Change Log from the source tarball package.</p>
      </div>

      <div class="SECT3">
        <h3 class="SECT3"><a name="NEWRELEASE-WINDOWS" id=
        "NEWRELEASE-WINDOWS">6.3.6. Windows</a></h3>

        <p>You should ensure you have the latest version of Cygwin (from
        <a href="http://www.cygwin.com/" target=
        "_top">http://www.cygwin.com/</a>). Run the following commands from
        within a Cygwin bash shell.</p>

        <p>First, <span class="emphasis EMPHASIS c2">make sure that you have
        freshly exported the right version into an empty directory</span>.
        (See "Building and releasing packages" above). Then get the Windows
        setup module:</p>

        <table class="c3" border="0" width="100%">
          <tr>
            <td>
              <pre class="PROGRAMLISTING">
  cvs -z3  -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co winsetup
</pre>
            </td>
          </tr>
        </table>

        <p>Then you can build the package. This is fully automated, and is
        controlled by <tt class="FILENAME">winsetup/GNUmakefile</tt>. All you
        need to do is:</p>

        <table class="c3" border="0" width="100%">
          <tr>
            <td>
              <pre class="PROGRAMLISTING">
  cd winsetup
  make
</pre>
            </td>
          </tr>
        </table>

        <p>Now you can manually rename <tt class=
        "FILENAME">privoxy_setup.exe</tt> to <tt class=
        "FILENAME">privoxy_setup_X_Y_Z.exe</tt>, and upload it to
        SourceForge. When releasing the package on SourceForge, use the
        release notes and Change Log from the source tarball package.</p>
      </div>

      <div class="SECT3">
        <h3 class="SECT3"><a name="NEWRELEASE-DEBIAN" id=
        "NEWRELEASE-DEBIAN">6.3.7. Debian</a></h3>

        <p>First, <span class="emphasis EMPHASIS c2">make sure that you have
        freshly exported the right version into an empty directory</span>.
        (See "Building and releasing packages" above). Then add a log entry
        to <tt class="FILENAME">debian/changelog</tt>, if it is not already
        there, for example by running:</p>

        <table class="c3" border="0" width="100%">
          <tr>
            <td>
              <pre class="PROGRAMLISTING">
  debchange -v 3.0.19-stable-1 "New upstream version"
</pre>
            </td>
          </tr>
        </table>

        <p>Then, run:</p>

        <table class="c3" border="0" width="100%">
          <tr>
            <td>
              <pre class="PROGRAMLISTING">
  dpkg-buildpackage -rfakeroot -us -uc -b
</pre>
            </td>
          </tr>
        </table>

        <p>This will create <tt class=
        "FILENAME">../privoxy_3.0.19-stable-1_i386.deb</tt> which can be
        uploaded. To upload the package to Sourceforge, simply issue</p>

        <table class="c3" border="0" width="100%">
          <tr>
            <td>
              <pre class="PROGRAMLISTING">
  make debian-upload
</pre>
            </td>
          </tr>
        </table>
      </div>

      <div class="SECT3">
        <h3 class="SECT3"><a name="NEWRELEASE-MACOSX" id=
        "NEWRELEASE-MACOSX">6.3.8. Mac OS X</a></h3>

        <p>First, <span class="emphasis EMPHASIS c2">make sure that you have
        freshly exported the right version into an empty directory</span>.
        (See "Building and releasing packages" above). Then get the Mac OS X
        setup module:</p>

        <table class="c3" border="0" width="100%">
          <tr>
            <td>
              <pre class="PROGRAMLISTING">
  cvs -z3 -d:pserver:anonymous@ijbswa.cvs.sourceforge.net:/cvsroot/ijbswa co osxsetup
</pre>
            </td>
          </tr>
        </table>

        <p>Then run:</p>

        <table class="c3" border="0" width="100%">
          <tr>
            <td>
              <pre class="PROGRAMLISTING">
  cd osxsetup
  build
</pre>
            </td>
          </tr>
        </table>

        <p>This will run <tt class="FILENAME">autoheader</tt>, <tt class=
        "FILENAME">autoconf</tt> and <tt class="FILENAME">configure</tt> as
        well as <tt class="FILENAME">make</tt>. Finally, it will copy over
        the necessary files to the ./osxsetup/files directory for further
        processing by <tt class="FILENAME">PackageMaker</tt>.</p>

        <p>Bring up PackageMaker with the PrivoxyPackage.pmsp definition
        file, modify the package name to match the release, and hit the
        "Create package" button. If you specify ./Privoxy.pkg as the output
        package name, you can then create the distributable zip file with the
        command:</p>

        <table class="c3" border="0" width="100%">
          <tr>
            <td>
              <pre class="PROGRAMLISTING">
  zip -r privoxyosx_setup_x.y.z.zip Privoxy.pkg
</pre>
            </td>
          </tr>
        </table>

        <p>You can then upload <tt class=
        "FILENAME">privoxyosx_setup_x.y.z.zip</tt> anonymously to <tt class=
        "FILENAME">uploads.sourceforge.net/incoming</tt>, create a release
        for it, and you're done. Use the release notes and Change Log from
        the source tarball package.</p>
      </div>

      <div class="SECT3">
        <h3 class="SECT3"><a name="NEWRELEASE-FREEBSD" id=
        "NEWRELEASE-FREEBSD">6.3.9. FreeBSD</a></h3>

        <p>Login to Sourceforge's compile-farm via ssh:</p>

        <table class="c3" border="0" width="100%">
          <tr>
            <td>
              <pre class="PROGRAMLISTING">
  ssh cf.sourceforge.net
</pre>
            </td>
          </tr>
        </table>

        <p>Choose the right operating system. When logged in, <span class=
        "emphasis EMPHASIS c2">make sure that you have freshly exported the
        right version into an empty directory</span>. (See "Building and
        releasing packages" above). Then run:</p>

        <table class="c3" border="0" width="100%">
          <tr>
            <td>
              <pre class="PROGRAMLISTING">
  cd current
  autoheader &amp;&amp; autoconf &amp;&amp; ./configure
</pre>
            </td>
          </tr>
        </table>

        <p>Then run:</p>

        <table class="c3" border="0" width="100%">
          <tr>
            <td>
              <pre class="PROGRAMLISTING">
  gmake freebsd-dist
</pre>
            </td>
          </tr>
        </table>

        <p>which creates a gzip'ed tar archive. Sadly, you cannot use
        <b class="COMMAND">make freebsd-upload</b> on the Sourceforge machine
        (no ncftpput). You now have to manually upload the archive to
        Sourceforge's ftp server and release the file publicly. Use the
        release notes and Change Log from the source tarball package.</p>
      </div>

      <div class="SECT3">
        <h3 class="SECT3"><a name="NEWRELEASE-HPUX" id=
        "NEWRELEASE-HPUX">6.3.10. HP-UX 11</a></h3>

        <p>First, <span class="emphasis EMPHASIS c2">make sure that you have
        freshly exported the right version into an empty directory</span>.
        (See "Building and releasing packages" above). Then run:</p>

        <table class="c3" border="0" width="100%">
          <tr>
            <td>
              <pre class="PROGRAMLISTING">
  cd current
  autoheader &amp;&amp; autoconf &amp;&amp; ./configure
</pre>
            </td>
          </tr>
        </table>

        <p>Then do FIXME.</p>
      </div>

      <div class="SECT3">
        <h3 class="SECT3"><a name="NEWRELEASE-AMIGA" id=
        "NEWRELEASE-AMIGA">6.3.11. Amiga OS</a></h3>

        <p>First, <span class="emphasis EMPHASIS c2">make sure that you have
        freshly exported the right version into an empty directory</span>.
        (See "Building and releasing packages" above). Then run:</p>

        <table class="c3" border="0" width="100%">
          <tr>
            <td>
              <pre class="PROGRAMLISTING">
  cd current
  autoheader &amp;&amp; autoconf &amp;&amp; ./configure
</pre>
            </td>
          </tr>
        </table>

        <p>Then do FIXME.</p>
      </div>

      <div class="SECT3">
        <h3 class="SECT3"><a name="NEWRELEASE-AIX" id=
        "NEWRELEASE-AIX">6.3.12. AIX</a></h3>

        <p>Login to Sourceforge's compilefarm via ssh:</p>

        <table class="c3" border="0" width="100%">
          <tr>
            <td>
              <pre class="PROGRAMLISTING">
  ssh cf.sourceforge.net
</pre>
            </td>
          </tr>
        </table>

        <p>Choose the right operating system. When logged in, <span class=
        "emphasis EMPHASIS c2">make sure that you have freshly exported the
        right version into an empty directory</span>. (See "Building and
        releasing packages" above). Then run:</p>

        <table class="c3" border="0" width="100%">
          <tr>
            <td>
              <pre class="PROGRAMLISTING">
  cd current
  autoheader &amp;&amp; autoconf &amp;&amp; ./configure
</pre>
            </td>
          </tr>
        </table>

        <p>Then run:</p>

        <table class="c3" border="0" width="100%">
          <tr>
            <td>
              <pre class="PROGRAMLISTING">
  make aix-dist
</pre>
            </td>
          </tr>
        </table>

        <p>which creates a gzip'ed tar archive. Sadly, you cannot use
        <b class="COMMAND">make aix-upload</b> on the Sourceforge machine (no
        ncftpput). You now have to manually upload the archive to
        Sourceforge's ftp server and release the file publicly. Use the
        release notes and Change Log from the source tarball package.</p>
      </div>
    </div>

    <div class="SECT2">
      <h2 class="SECT2"><a name="RELEASING" id="RELEASING">6.4. Uploading and
      Releasing Your Package</a></h2>

      <p>After the package is ready, it is time to upload it to SourceForge,
      and go through the release steps. The upload is done via FTP:</p>

      <ul>
        <li>
          <p>Upload to: <a href="ftp://upload.sourceforge.net/incoming"
          target="_top">ftp://upload.sourceforge.net/incoming</a></p>
        </li>

        <li>
          <p>user: <tt class="LITERAL">anonymous</tt></p>
        </li>

        <li>
          <p>password: <tt class=
          "LITERAL">ijbswa-developers@lists.sourceforge.net</tt></p>
        </li>
      </ul>

      <p>Or use the <b class="COMMAND">make</b> targets as described
      above.</p>

      <p>Once this done go to <a href=
      "https://sourceforge.net/project/admin/editpackages.php?group_id=11118"
      target=
      "_top">https://sourceforge.net/project/admin/editpackages.php?group_id=11118</a>,
      making sure you are logged in. Find your target platform in the second
      column, and click <tt class="LITERAL">Add Release</tt>. You will then
      need to create a new release for your package, using the format of
      <tt class="LITERAL">$VERSION ($CODE_STATUS)</tt>, e.g. <span class=
      "emphasis EMPHASIS c2">3.0.19 (beta)</span>.</p>

      <p>Now just follow the prompts. Be sure to add any appropriate Release
      notes. You should see your freshly uploaded packages in <span class=
      "QUOTE">"Step 2. Add Files To This Release"</span>. Check the
      appropriate box(es). Remember at each step to hit the <span class=
      "QUOTE">"Refresh/Submit"</span> buttons! You should now see your
      file(s) listed in Step 3. Fill out the forms with the appropriate
      information for your platform, being sure to hit <span class=
      "QUOTE">"Update"</span> for each file. If anyone is monitoring your
      platform, check the <span class="QUOTE">"email"</span> box at the very
      bottom to notify them of the new package. This should do it!</p>

      <p>If you have made errors, or need to make changes, you can go through
      essentially the same steps, but select <tt class="LITERAL">Edit
      Release</tt>, instead of <tt class="LITERAL">Add Release</tt>.</p>
    </div>

    <div class="SECT2">
      <h2 class="SECT2"><a name="AFTERRELEASE" id="AFTERRELEASE">6.5. After
      the Release</a></h2>

      <p>When all (or: most of the) packages have been uploaded and made
      available, send an email to the <a href=
      "mailto:ijbswa-announce@lists.sourceforge.net" target="_top">announce
      mailing list</a>, Subject: "Version X.Y.Z available for download". Be
      sure to include the <a href=
      "http://sourceforge.net/project/showfiles.php?group_id=11118" target=
      "_top">download location</a>, the release notes and the Changelog.
      Also, post an updated News item on the project page Sourceforge, and
      update the Home page and docs linked from the Home page (see below).
      Other news sites and release oriented sites, such as Freshmeat, should
      also be notified.</p>
    </div>
  </div>

  <div class="NAVFOOTER">
    <hr class="c1" width="100%">

    <table summary="Footer navigation table" width="100%" border="0"
    cellpadding="0" cellspacing="0">
      <tr>
        <td width="33%" align="left" valign="top"><a href="testing.html"
        accesskey="P">Prev</a></td>

        <td width="34%" align="center" valign="top"><a href="index.html"
        accesskey="H">Home</a></td>

        <td width="33%" align="right" valign="top"><a href=
        "webserver-update.html" accesskey="N">Next</a></td>
      </tr>

      <tr>
        <td width="33%" align="left" valign="top">Testing Guidelines</td>

        <td width="34%" align="center" valign="top">&nbsp;</td>

        <td width="33%" align="right" valign="top">Update the Webserver</td>
      </tr>
    </table>
  </div>
</body>
</html>
